home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re FW_CSharedLibraryResourceFil < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re:FW_CSharedLibraryResourceFile
  2. Sent:        6/3/96 8:21 AM
  3. Received:    6/3/96 8:41 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 11:12 PM 6/2/96, Hutchings Software Development wrote:> If I allocate a
  9. FW_CSharedLibraryResourceFile with the constructor that
  10. > just passes the Environment* parameter, is that guaranteed to open access
  11. > to the part editor's shared library?
  12. >
  13. > That piece of info was missing from ODF Assistant in QuickView.
  14. >
  15. > I need to know this because I'm writing a general utility routine for
  16. > "CustomGetFolder", and I need acces to my part editor's resource fork,
  17. > hopefully without passing an FW_Instance parameter all over the place.
  18. >
  19. > Thanks,
  20. >
  21. > Brad
  22.  
  23. Brad,
  24.  
  25. As you well know by now, dealing with Macintosh resources in the OpenDoc
  26. world is confusing.  Now I'll make it more confusing. Think of
  27. FW_CSharedLibraryResourceFile as a file specifier. That's really all that
  28. it is. Once you've created a FW_CSharedLibraryResourceFile, you can pass it
  29. to any interface that accepts a FW_PResourceFile. Most resource access in
  30. ODF parts is accomplished by calling the resource acquisition utilities
  31. that expect an FW_PResourceFile. Resource acquisition methods dynamically
  32. adjust the Macintosh resource chain, putting your parts resource fork at
  33. the head of the chain only when you attempt to get a resource. This is so
  34. because all parts living in a single document share the same resource
  35. chain, and we do our best to prevent collisions.
  36.  
  37. It sounds to me like what you are doing is a bit different. I suspect you
  38. want to call the toolbox Standard File package, and pass the resource id of
  39. your custom get file dialog. You've probably noticed that the toolbox
  40. interfaces don't take FW_PResourceFile parameters. Creating an
  41. FW_CLibrarySharedResourceFile before calling the toolbox interfaces will
  42. have no effect, and you're likely to get unexpected behavior.
  43.  
  44. In this case, you need to create a stack-based instance of
  45. FW_CAcquireCFMResourceAccess. Creating one of these on the stack is similar
  46. to calling UseResFile. FW_CAcquireCFMResourceAccess's destructor will take
  47. care of cleanup and is exception safe. Just make sure you scope your code
  48. such that your FW_CAcquireCFMResourceAccess falls out of scope and is
  49. destroyed before you attempt to call any OpenDoc or ODF methods that might
  50. try to get to resources.
  51.  
  52. gsf.
  53.  
  54.  
  55.  
  56. _________________________________________________________
  57. Greg Friedman      ODF Engineering       Apple Computer
  58.  
  59.